A portion of the disclosure of this patent document may contain command formats and/or other computer language listings, all of which are subject to copyright protection. The copyright owner, EMC Corporation, has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The present invention relates to apparatus, methodology, systems, and/or computer program product for monitoring nodes in a client server environment and, more particularly, relates to the handling of client and/or server failure modes associated with the processing of indications which are sent from indication publishers or sources in those servers to indication subscribers in those clients.
2. Description of Prior Art
Client-server network configurations are well known in the computer arts. A client requests information and such information is provided, or served-up, by its server(s). A human user of the network, or his/her graphical user interface (GUI), can be conceptualized as a “client” who is being served by the network or the network's components. Reference is made to FIG. 1 wherein network 100 shows user interface or client 101 in communication with servers 102, 103, and 104 over bus structure 105. Client 101 makes requests of any one or more of these servers which provide, or serve up, the requested information back to the client over the bus. And, within the nodes of such network (within client 101 or any of the servers), inanimate hardware/software sub-systems, other nodes, or processes that are being “served” in some capacity by other such sub-systems, nodes, or processes (“servers”) are also referred to as “clients” of those servers.
Management of these client-server networks is a very important function that must be maintained to ensure that the networks operate as intended and serve network users as expected. This management function may be accomplished through distributed management software which can be distributed within a client-server network. If a client-server network is running such software that is also object-oriented, typically many objects reside in each of the clients and/or servers. Information from each of these objects may be necessary to satisfy certain information requests in pursuit of executing certain distributed management software functions. An object, in computer software terms, is a dedicated area of memory which can be thought of as an impervious container holding both data and instructions within itself, both defining itself and its relationships to other objects in the computer system or network. An object can send and receive messages to and from other objects, respond and react to such messages (e.g. commands) but shall normally be impervious to internal scrutiny. For example, in a storage processor (a kind of computer) each object may describe or relate to a specific tangible detail in the processor (e.g. a fan, power switch, cache memory, power supply, disk drive interface, etc.), where these tangible objects in the storage processor can send messages to each other and to other objects outside the processor.
As noted, it is important to have this management software run as efficiently as possible. In order to manage various components of a client-server network such as a storage network, there has to be frequent, if not continuous, monitoring of operation of at least the important objects comprising various critical aspects of, for example, a storage system in that storage network. One of the techniques used to monitor objects within an object-oriented network involves “observers” or “observer objects” which are used to observe or monitor “subject objects”. When a subject object changes state, it “fires back” an instantaneous indication thereof to a component that is interested in the state change of that subject object. The subject object is the “indication source”. The “indication” is the message sent by subject object to observer object, or from server to client, to indicate a change has occurred. The observer or its client can be viewed as an “indication subscriber” or a “subscriber to indications” where the observer observes the change of state and its client is interested in the change. The “indication subscription” is the “request” for the indication or state-change-message, and reflects the interest that the subscriber or client has in the event. “Observer infrastructure” is whatever is required to enable the indication to be sent from subject object to observer object. The subject object can be grouped with other objects within a package termed a “provider”.
That change of state, once detected and communicated by way of this observer or indication technique, can then be managed by the distributed management software. This activity is termed “asynchronous” notification, which is very efficient as contrasted with slower and arguably more complex prior notification techniques which provided each notification only in response to an individual request. Asynchronous notification does not have to wait for an individual request to be made—it employs objects which are set at “hair-trigger” alertness to react simultaneously with observed state changes in their respective subject objects.
Industry standards committees have evolved to bring uniformity to different developmental directions where possible. One such committee is known as Distributed management Task Force (DMTF) and has generated a particular standard called Web Based Enterprise Management (WBEM) using the Common Information Model (CIM). Asynchronous notifications may now be implemented substantially in accordance with CIM and the WBEM standard. Asynchronous notification was used, and observers were discussed, in U.S. patent application Ser. No. 10/027,694 filed Dec. 20, 2001, entitled: “Data Replication Facility for Distributed Computing Environments”, inventors: R. J. Nordin, A. L. Bauer, S. Krishnan, and G. W. Lazar, assigned to the assignee of the instant application, and hereby incorporated herein by reference in its entirety. For further background information on the subject of observers, a good text reference is: “Design Patterns”, authored by Erich Gamma, et al, published by Addison-Wesley, Chapter 5, starting at page 293 thereof, such chapter hereby incorporated herein by reference in its entirety.
However, despite the improved efficiencies provided by asynchronous notification, there are shortcomings related to failures of client or server. For example, the client itself may fail, or the server itself may fail, or power to either may be interrupted causing failure, or connections between client and server which carry these asynchronous notifications may not stay connected in every instance. Therefore, there is a need for handling client or server related failures in a manner that mitigates their impact. Applicants' invention provides techniques for handling these problems.